Columbia Kermit/kermit.zip/newsgroups/misc.20041116-20060924/[e-mail]_Sun Mar 19 14:56:47 2006.msg

Internet Message Format | 2020-01-01 | 6KB

Path: newsmaster.cc.columbia.edu!panix!newsfeed-00.mathworks.com!newscon06.news.prodigy.com!prodigy.net!border1.nntp.dca.giganews.com!nntp.giganews.com!nf3.bellglobal.com!ursa-nb00s0.nbnet.nb.ca!53ab2750!not-for-mail
From: "Scott Caissie" <[e-mail]>
Newsgroups: comp.protocols.kermit.misc
References: <uGRPf.40748$[e-mail]> <kLSPf.9392$[e-mail]> <[e-mail]> <RqZPf.40942$[e-mail]> <[e-mail]> <H81Qf.41050$[e-mail]> <ok2Qf.12766$[e-mail]> <aQkQf.41491$[e-mail]> <pVlQf.14280$[e-mail]>
Subject: Re: closing a macro completely upon connect
Lines: 115
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Message-ID: <ATwQf.41716$[e-mail]>
Date: Sat, 11 Mar 2006 09:37:36 GMT
NNTP-Posting-Host: 156.34.15.45
X-Complaints-To: [e-mail]
X-Trace: ursa-nb00s0.nbnet.nb.ca 1142069856 156.34.15.45 (Sat, 11 Mar 2006 05:37:36 AST)
NNTP-Posting-Date: Sat, 11 Mar 2006 05:37:36 AST
Organization: Aliant Internet
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15521

> Macros only execute in "command mode".  Its been several years since I
> fixed the bug associated with SET KEY and terminal mode, but my
> recollection is that the macro would be configured to execute and
> "terminal or connect mode" would not be exited.

Its this that I'm trying to understand.
You're saying that Macros can be executed in connect mode BUT can not run in
connect mode with the fix?
Then this fix is something that has no use to me.
I already created a work around to activate any macro via connect mode. I
want it to actively run while in connect mode.

This here was worded bad:
ftp://kermit.columbia.edu/kermit/k95/newbugs.txt
735. Macros on Keys broken

In versions 1.1.21 through 2.1.3, when a SET [TERMINAL] KEY definition
includes a macro invocation, then pressing the key while in the
Terminal screen returns to the command screen (and in some cases might
also fail to execute the macro).

All this time I was thinking the act of going to the command screen upon
invokation was the bug itself. It says 2 things. The secondary issue isn't a
concern.


Background program:
Actively saving the scrollback buffer and analying the last 30 lines which
is slightly more than a full screen worth of work, and do various events.
I have about 7-8 macros which upon activation causes a 'blink' effect. Jumps
to the command window, does the code involving the scrollback or something
else, and jumps back to the terminal. As far as my co-workers are concerned,
the macro 'reads the screen'. I wanted to remove the 'blink' effect. Not all
the users are comfortable with something that visually appears unstable.


I do have a technical question.
Lets say I have a macro that calls another macro (which this buggy one
does). If success, it does XX and Connects. If failure, it does nothing
aside from Connects.
Now if the ONLY means of getting to the Command window is through a Macro'd
hotkey, when it is used, does it cancel the immidate macro (which was paused
via the Connect command), or does it cancel all levels of the macro? (ie:
The parent macro which summoned it?). I think that is what is happening.
That afterall is what this thread is about. Not the macro invokation bug,
but the Macros being nested issue.

define test1 {
.......
; checks keyboard cursor location. if success, then it does the rest
; this allows 1 key to be used to activate many macros. 1 at a time though
based on where you are in your work
; until this point, I never had macros calling macros.
if .... do test2
connect
return
}
define test2 {
; read scrollback
; output value
connect
return
}



"Jeffrey Altman" <[e-mail]> wrote in message
news:pVlQf.14280$[e-mail]...
> Scott Caissie wrote:
>> But I still need to know what is being fixed.
>> Fix basically states that macros can be run from the Terminal without the
>> screen changing.
>
> Where does http://www.columbia.edu/~jaltman/k95-fixes-since-213.txt
> indicate that?
>
>> But normally, no complex macros can run (with or without set key) while
>> actively in the Terminal. They basically pause until you go back into the
>> Command window.
>
> Macros only execute in "command mode".  Its been several years since I
> fixed the bug associated with SET KEY and terminal mode, but my
> recollection is that the macro would be configured to execute and
> "terminal or connect mode" would not be exited.
>
>> Can we have things running in the background now while in the Terminal?
>
> You cannot have things executing in the background while in terminal
> mode.  Terminal mode is the "CONNECT" command.  When the terminal window
> is displayed the command processor is blocked in "CONNECT".  Why is
> this?  Because the input and output devices are controlled by the user
> when the CONNECT command is executed.  The input and output devices
> cannot be tampered with by a script.
>
> The CONNECT command provides a trigger functionality that allows a
> script to be executed when specific input patterns are recognized.
> There is also an ability to automated output based upon idle timers.
>
> What is it that you want to run in the background that would not be
> competing with the user interaction with the remote host?
>
>> Thats what it sounds like. Though as far as I know, only 1 macro can run
>> at
>> a time. Invoking a macro in the Terminal while another macro (in a loop)
>> is
>> running in the background will cause the one in the background to stop
>> would
>> it not?
>
> You are correct.  There is one command processor and therefore one macro
> at a time.  This has not changed.
>
> Jeffrey Altman